feat(core): split exports by browser/server for bundle size#20435
feat(core): split exports by browser/server for bundle size#20435
Conversation
143a2a5 to
1494709
Compare
size-limit report 📦
|
d5dddbf to
8eba1e9
Compare
8eba1e9 to
8ea4f5c
Compare
8ea4f5c to
787f44b
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs, in `@sentry/core` where they can be easily shared across runtimes. Integration may require updating our `tsconfig` settings so that tsc knows it is allowed to look on `package.json` exports. fix: #20434 fix: JS-2243
787f44b to
7076f7c
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs, in `@sentry/core` where they can be easily shared across runtimes. Integration may require updating our `tsconfig` settings so that tsc knows it is allowed to look on `package.json` exports. fix: #20434 fix: JS-2243
7076f7c to
e2cf052
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs, in `@sentry/core` where they can be easily shared across runtimes. Integration may require updating our `tsconfig` settings so that tsc knows it is allowed to look on `package.json` exports. fix: #20434 fix: JS-2243
e2cf052 to
67bf5c4
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. fix: #20434 fix: JS-2243
67bf5c4 to
2cf15db
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. fix: #20434 fix: JS-2243
2cf15db to
c1c9cf0
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. fix: #20434 fix: JS-2243
c1c9cf0 to
5beb2e3
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. In particular, we cannot use the `module: "node"` option, or `moduleResolution: "node"`. In many cases, this means either using `module: "esnext"` and `moduleResolution: "bundler"`, so that tsc lets the bundler handle the assembly, or `nodenext` or `node16` for both `module` and `moduleResolution`. fix: #20434 fix: JS-2243
5beb2e3 to
ca38b53
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. In particular, we cannot use the `module: "node"` option, or `moduleResolution: "node"`. In many cases, this means either using `module: "esnext"` and `moduleResolution: "bundler"`, so that tsc lets the bundler handle the assembly, or `nodenext` or `node16` for both `module` and `moduleResolution`. fix: #20434 fix: JS-2243
ca38b53 to
24304fe
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 24304fe. Configure here.
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. In particular, we cannot use the `module: "node"` option, or `moduleResolution: "node"`. In many cases, this means either using `module: "esnext"` and `moduleResolution: "bundler"`, so that tsc lets the bundler handle the assembly, or `nodenext` or `node16` for both `module` and `moduleResolution`. fix: #20434 fix: JS-2243
24304fe to
da8cd5a
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. In particular, we cannot use the `module: "node"` option, or `moduleResolution: "node"`. In many cases, this means either using `module: "esnext"` and `moduleResolution: "bundler"`, so that tsc lets the bundler handle the assembly, or `nodenext` or `node16` for both `module` and `moduleResolution`. fix: #20434 fix: JS-2243
da8cd5a to
8fe31cb
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. In particular, we cannot use the `module: "node"` option, or `moduleResolution: "node"`. In many cases, this means either using `module: "esnext"` and `moduleResolution: "bundler"`, so that tsc lets the bundler handle the assembly, or `nodenext` or `node16` for both `module` and `moduleResolution`. fix: #20434 fix: JS-2243
8fe31cb to
28b47ec
Compare
Split the exports from `@sentry/core` into three options: - `@sentry/core`, the default (unchanged) - `@sentry/core/browser`, containing _only_ shared and browser-specific functionality, nothing server-specific. - `@sentry/core/server`, containing _only_ shared and server-specific functionality, nothing browser-specific. This should allow us to make the bundle sizes quite a bit smaller in our browser SDKs where this is important, while adding more functionality to our server-specific SDKs in `@sentry/core`, where they can more easily be shared across runtimes. Some integration requires updating `tsconfig` settings so that tsc knows it is allowed to look up `package.json` exports. In particular, we cannot use the `module: "node"` option, or `moduleResolution: "node"`. In many cases, this means either using `module: "esnext"` and `moduleResolution: "bundler"`, so that tsc lets the bundler handle the assembly, or `nodenext` or `node16` for both `module` and `moduleResolution`. fix: #20434 fix: JS-2243
28b47ec to
a783c2e
Compare
JPeer264
left a comment
There was a problem hiding this comment.
Do you think it would make sense to add size limit / bundle checks for these exports?
| @@ -1,4 +1,4 @@ | |||
| import { getActiveSpan, SentrySpan } from '@sentry/core'; | |||
There was a problem hiding this comment.
q: Are these changes actually needed? I would assume @sentry/core could automagically detect which bundle it should take no?
There was a problem hiding this comment.
It's needed in tests usually just so that vitest mocks the correct core export, and it was easier to just use a perl one-liner to update all the imports in all the tests in a given package if it's strictly browser or server.

Split the exports from
@sentry/coreinto three options:@sentry/core, the default (unchanged)@sentry/core/browser, containing only shared and browser-specificfunctionality, nothing server-specific.
@sentry/core/server, containing only shared and server-specificfunctionality, nothing browser-specific.
This allows us to make the bundle sizes quite a bit smaller in our
browser SDKs where this is important, while adding more functionality to
our server-specific SDKs, in
@sentry/corewhere they can be easilyshared across runtimes.
fix: #20434
fix: JS-2243